This invention relates to analysis of compressed video signals, and more particularly to a method and apparatus for analyzing a transport stream for a compressed video signal.
In known monitors for real-time monitoring and analysis of compressed video signals, such as MPEG-2 compressed video signals, transport stream packets of the video signal are received by the monitor and analyzed sequentially in the order in which they are received. However, such stream analysis requires greater computational power than merely receiving the video signal in a set top box or other MPEG stream receiver. This is not only because the analyzer must analyze all the services in the stream, whereas the receiver receives only a single service, but because in addition some items in the stream take considerably more power to analyze than they do to use. For example, Program Clock Reference (PCR) values are analyzed by applying a best-fit line algorithm to the data whereas in a receiver the values are fed directly into a phase locked loop without analysis. As a result of the computational requirements of analysis, and the practical limits on computational power that may realistically and cost-efficiently be provided, the transport stream of a compressed video signal may contain more information than can be analyzed in real time. As a result the monitor may become overloaded, causing the monitor to perhaps crash, reset or randomly drop packets.
An MPEG-2 transport stream typically carries multiple programs or services. Such transport streams may carry up to 150 programs. The transport stream has program elements in packets, each packet being identified by a Packet Identifier (PID). Program Association Tables (PATs) are included as packets in the transport stream. The PATs list for each program PIDs that identify Program Map Tables (PMTs) which describe the program and provide PIDs for constituents of a given program. Each of the programs transmitted in the transport stream is assigned a Program Number in the PAT and the respective Program Numbers also appear in each PMT. These tables are repeated approximately every two second in the transport stream so that a PAT is received within approximately two seconds after switching on a receiver to initiate service to the receiver. European Telecommunications Standards Institute (ETSI) standard TR 101 290, available from ETSI, 650 Route des Lucioles, F-06921 Sophia Sntipolis Cedex, France, stipulates that a PMT should appear in the transport stream within every half second for each PMT packet identifier. However even though a transport stream may pass this basic test, this does not test whether all of the PMTs for each program having PIDs assigned by the PATs are present in the transport stream.
Also included in the transport stream there are repeated instances of a Service Description Table (SDT) describing each of the services or programs being transmitted by that transport stream. Included for example are a program name for each service, which may be displayed at a receiver when a user receives a service. This is referred to as the actual SDT. For example where the service is a broadcast television channel, the name of the channel may be displayed on a television receiver. There may also be included in the transport stream other SDTs giving details of services being transmitted in other transport streams, such as at other radio frequencies, that are also receivable by the receiver. This provides the user the ability to transparently receive details of all receivable services without needing to be aware that they are transmitted in different transport streams, or in which transport streams they are transmitted. ETR 211 “Digital Video Broadcasting (DVB); DVB Guidelines for Implementation and Usage of Service Information (SI)”, also available from ETSI, makes the inclusion of an actual SDT mandatory and requires that the SDT of an actual transport stream shall list at least all the services or programs of that transport stream. In addition any SDT for another transport stream than the actual transport stream in which the SDT is transmitted shall list all the services or programs of that other transport stream. Each of the programs transmitted in the transport stream is assigned a Program Number in the PAT, as indicated above, and the respective Program Numbers also appear in the SDT, the Program Number or Service Identity (SID) being unique within each transport stream. These tables are repeated approximately every two seconds, like the PMTs, so that an SDT is received also within approximately two seconds of a user seeking details of programs being transmitted in the transport stream. ESTI standard TR 101 290, referenced above, stipulates that an actual SDT should appear in the transport stream every two seconds. However even though a transport stream may pass this basic test, this does not test whether SDTs contain details of all the services being transmitted in the transport stream as required by the standard. This may result in a failure to name a program being received by failing to display the program identifier.
Further included as packets in the transport stream may be Master Guide Tables (MGTs) that list PIDs for all other tables which should be present in the transport stream apart from a System Time Table. ATSC Standard A/65 “Program and System Information Protocol for Terrestrial Broadcast and Cable” requires the presence in transport streams for terrestrial transmission of an MGT and also four Event Information Tables EIT-0, EIT-1, EIT-2 and EIT-3. Terrestrial transport streams are recognizable by the presence of a Terrestrial Virtual Channel Table (TVCT) type entry. The Event Information Guides list the programs to be transmitted in each of three-hour sessions, EIT-0 being the current session, EIT-1 being the next three-hour session, etc. Other EITs for later periods of time, for example up to a weeks programming, may optionally also be included. There is no requirement in the standard for EITs in satellite or cable transport streams. It is not necessarily known a priori when testing a transport stream whether it is a terrestrial transport stream. Even if it is known, there are no guidelines in the standard on how to monitor whether a terrestrial transport stream meets the standard in respect to the presence of EITs.
What is desired is a method of preventing a compressed video signal monitor from becoming overloaded while analyzing and verifying complete conformance with appropriate standards.